Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
The notion of context-aware recommendation mechanisms typically is limited to recommending content based on current location, content, or a user profile. For example, when a user looks at a customer account in a CRM (customer relations management) system, a content recommendation component may pull up information related to the customer's account based on structured or fuzzy relationships. If actions related to a customer account object are modeled, the system may additionally list system functions that correspond to user actions that can be launched in combination with that account. In all such cases, the system does not develop a machine-executable understanding of a larger task context, but rather opportunistically recommends related content based only on the current content. In other words, the system knows only what content is currently selected, but not why.
Conventional approaches are not sufficient to provide procedural guidance in which tools and practices may be recommended based on an understanding of the task context and actions as part of a larger task context. Common approaches typically are centered around modeling concepts being representative of the particular field or domain while not considering the semantics of such concepts within a particular business situation or task As such, they fail to acknowledge that associations between structural entities, e.g., actors and artifacts, need to be characterized by additional relations that apply only for specific situations.
The adoption of semantic modeling technologies is somewhat limited due to the high investment in feeding semantic models with knowledge until an inference engine can make recommendations useful for completing the task. The task may be impractical in an existing enterprise where a great deal history and context has accumulated. Such modeling also requires special skills, typically the effort of knowledge engineers who are proficient in semantic representation methods such as OWL or Prolog. Domain-experts who have a sound understanding of concepts and rules for a particular domain are typically not able to create such models due to the level of abstraction and special syntax.
A successful design time for implementing task models and instrumenting software to inform task awareness engines must therefore consider the different expert profiles and locality of modeling different abstraction levels. These and other issues are addressed by embodiments of the present invention, individually and collectively.